Positioning for Mvs / Esa Sp 5

IBM’s latest hardware facilities (Parallel Transaction Servers and the Coupling Facility) and software (MVS/SP 5 with its new WLM Workload Manager) are exciting and promise to offer relief in the cost of mainframe applications and ease of managing the resources. To gain immediate and valuable use of the new facilities, however, you should start your migration plan early -as in NOW! The speaker, who’s been tuning systems since 1965, is looking forward to the changes and provides some hints, tips, recommendations, and just plain common sense in preparing for these new facilities. She’ll look at what to do about service level objectives now, a year or more before moving to the new Workload Manager. (It will take more than a simple conversion of a few IPS parameters!) You can’t prepare too early for the latest release of MVS, so here’s your chance to start. Before you can decide if and when you’re going to move to SP 5, you should consider the benefits and costs, both tangible and intangible. The first sections of this article describe these pros and cons. I’ve recently been asked whether I’d recommend moving to SP 4.3 or directly to SP 5.1, and one section provides my answer to that. The majority of sections, however, deal with how to prepare for SP 5, even if you’re still at XA. There are many things you can do to position yourself for SP 5 that will also provide real benefits today. With proper positioning, the migration to SP 5 will be extremely easy, as well as beneficial. These comments apply both to SP 5.1, which is available today, as well as SP 5.2, which will be available in the first quarter of 1995. ADVANTAGES OF MVS/ESA SP 5 If you’re running any release of MVS today, you know that at some point in the future you’ll probably move to SP 5 (or 6 or 7), since that will eventually be the only version supported. (Elimination of support for MVS/XA, for instance, was scheduled for 9/30/94, but is being extended to 9/30/95 to “facilitate customer migrations to newer versions of MVS”). If you want to know what's in it for you today, here are the major benefits of SP 5. (This article was originally written describing the considerations for moving to SP 5.1. On September 13, 1994, MVS/ESA SP 5.2 was announced, with availability in the first quarter of 1995. All of the comments in the article apply to both SP 5.1 and 5.2, unless specifically indicated. You may still see references to 5.1, since that’s the release currently available and in use.) EXTENSION OF SYSPLEX SUPPORT “Sysplex” or “SYStem ComPLEX” is the term applied to the facility that provides a standard interface for subsystems that need to communicate with multiple systems (MVS images). Sysplex was introduced in SP 4.1, and was initially implemented in GRS, JES, VTAM, CICS, PR/SM recovery, and several other MVS facilities. The enhanced sysplex support available in SP 5 provides the basis for high speed data sharing among multiple systems within the sysplex. This is done via the new coupling technology introduced in SP 5.1 and further enhanced in SP 5.2. MVS is also enhanced to exploit this coupling facility in areas other than data sharing. This sysplex exploitation is provided to simplify the maintenance and management of both single and multiple MVS images. For example, SP 5 provides the ability to specify a single set of parameters for managing the workloads (using the Workload Manager as described later) and provides a method to define a course of action in the case of sysplex failures (through a sysplex failure management (SFM) policy). The ability to automatically recover from an outage that occurs within a single system sysplex may be all the justification you need to move to SP 5. SUPPORT FOR PARALLEL SYSPLEX IBM's announcements of their new S/390 CMOS parallel processors, the 9672-P and 9672-E Parallel Transaction Servers (PTS) and the 9672-R Parallel Enterprise Servers (PES), are among their most significant announcements to date. (CMOS, by the way, stands for Complementary Metal Oxide Semiconductor doesn’t that tell you a lot?) These less expensive air-cooled processors will allow installations to save the millions of dollars invested in MVS applications and avoid having to rewrite them to fit on UNIX or similar machines. Most of the companies that have been looking at downsizing are now evaluating the new CMOS processors as an alternative to downsizing. These new processors are only one step towards some significant improvements in price per MIPS that we'll soon see. IBM predicts that the speed of the CMOS processors will double in a very short while, and it won't be long until they match the speeds of the current large mainframe CPUs (while still available at lower cost). The announcement on September 13 of the PES machines indicated that the current range of machines is equivalent to (and ready to replace) the S/370 and S/390 machines from 4381, 308x, and 3090/180 up to a 3090/300S. A doubling of the speed of a CMOS processor would result in a machine that’s the equivalent of a 3090/520 based machine. One of the keys to using these new machines is the "Coupling Facility", which is the hardware and software that's used to allow quick communication between the CMOS processors and each other or multiple non-CMOS systems (511or 711-based machines). The new coupling facility also provides high speed data sharing, so that (eventually!) anyone, anywhere, can read or write a record within the enterprise (without contention delays). Parallel sysplex is the name given to the combination of facilities provided by the coupling facility, the hardware, and MVS/SP 5 that allows this easy and fast communication between multiple machines. This high speed data sharing is currently announced and available for IMS/DB and will soon be available for both DB2 and VSAM. The coupling facility and parallel sysplex require the functions provided by MVS/ESA SP 5. This is another major reason that installations will move to SP 5. It's a step on the way to lowering costs in the data center and that's what counts! WORKLOAD MANAGER (WLM) SP 5 provides an enhancement to the System Resources Manager (SRM) called the Workload Manager (WLM). This new feature is one of the main reasons to move to SP 5, regardless of your plans for parallel sysplex. The WLM has three primary objectives. The first objective of WLM is to simplify the management of the system resources, such as CPU and storage. Prior to the WLM, installations would try to allocate resources to address spaces by using parameters such as dispatch priority, storage isolation, expanded storage criteria ages, domain contention parameters, logical swap parameters, and many others. The WLM, instead, allows an installation to simply specify desired response time objectives and relative importance for the work, and then let the system work towards achieving those response time objectives by allocation of resources to the work in the system. This simplification of the parameters is a boon to already over-worked sysprogs. A second objective of WLM is to provide a single, complex-wide, consistent set of parameters for managing multiple workloads across multiple systems in a sysplex environment. If you plan to implement either a sysplex or a parallel sysplex, WLM can provide a simple means of defining your response time goals. Even with a single CEC today, such as an single ES/9000, you may be running four or five LPARs, each with their own ICS, IPS, and OPT parmlib members. With WLM and sysplex, you could manage those LPARs with a single set of specifications. A third, but related, objective of WLM is to provide support for other subsystems. Subsystems that take advantage of MVS workload manager services allow MVS to manage the subsystem regions according to the goals of the transactions they service. Thus, the performance administrator will be able to specify response time goals for their “CICS inventory” transactions and MVS will manage the CICS regions that process these “inventory” transactions according to the goals of these transactions. In addition, there is a product for CICS called CICSPlex System Manager (also referred to as CP/SM) that will dynamically route transactions to multiple CICS regions in an attempt to meet response goals. These CICS regions might even reside in different CECs in a sysplex environment. CICS 4.1 and IMS 5.1 provide support for WLM. Thus, WLM provides: 1) simplified externals 2) system resources managed according to customer goals for the work 3) management of subsystem address spaces according to the goals of the transactions (for subsystems that support WLM) 4) single system-wide specification of installation parameters 5) support to manage workloads across multiple CECs in a parallel sysplex As you can see, WLM alone is reason enough to move to SP 5. OPENEDITION MVS (RUN UNIX UNDER MVS!) As more and more companies investigate developing client/server applications and using existing UNIX applications, OpenEdition MVS (OMVS) is a facility that will become increasingly popular. OMVS is part of the base component of MVS in SP 5 that supports POSIX-compliant applications. (POSIX is a standard defined by the Open Software Foundation (OSF) for open systems applications, and is based on C-programs and UNIX techniques.) Since many, although not all, UNIX applications are POSIXcompliant, this base MVS support allows you to run these relatively inexpensive applications on your mainframe. The IBM announcement letter #294-152 indicates that some of the software products available with OpenEdition MVS in 1994 include TUXEDO (Information Management Co.), MOSAIC (The Mosaic Group), SAS, SAS/C, Omegamon (Candle), CaseWare CM (CaseWare, Inc.), ADABAS (Software AG), and CA-ACF@ (Computer Associates). I’ve talked to five different installations in the past month that are moving to 5.1 simply because their users had found some client/server applications that they wanted installed as soon as possible. In all cases, it made more sense to upgrade the MVS software and run the applications on the current mainframe than purchase, install, test, and put into production a separate hardware solution for the applications. Realize that some of the vendor products have not completed their move to a true POSIX-compliant status. Check with your prospective vendors to determine their current status and plans. I don’t know of any major UNIX software vendor that isn’t working on POSIX-compliance. Another reason that you might find a good use for OMVS is the availability of programmers that are UNIX-trained in school. As one manager puts it, “teach them TSO for a couple of days, and they’ll be able to develop applications in the OMVS environment”. OMVS supports the UNIX Hierarchical File System (HFS), which is implemented using a PDSE data set. Since PDSE requires SMS, at least an initial implementation of SMS is required for OMVS applications. OpenEdition MVS appears to be one of the fastest growing new application platforms on MVS. SUPPORT FOR 4-DIGIT DEVICE NUMBERS There are several installations that feel restricted by the current 3-digit device support. SP 5.1 now provides for 4-digit support. The initial implementation only allows between 1500 and 2000 more devices without incurring a virtual storage constraint below the line. That limitation is removed in SP 5.2 because the control blocks are moved above the 16MB line. There are some JCL changes necessary as soon as you start to use the 4-digit designation. The basic support for 4-digit device numbers is documented in the Conversion Notebook, but essentially consists of placing a “/” in front on any 4-digit number. As an example, consider the DD parameter, UNIT=. Currently, you can specify UNIT=SYSDA or UNIT=3390 to specify a generic device allocation. Reference to a specific device by device number, such as 590, would be included as: UNIT=590. With 4-digit device support, you could actually define a device with a number of 3390. The use of a “/” allows the interpreter to determine whether you’re specifying a generic or a specific device. Thus, UNIT=3390 refers to the generic name assigned to many 3390 devices, while UNIT=/3390 refers to the single device numbered 3390. CICS SUBSPACES In SP 4.2.2, support was provided to allow CICS system code to be protected from transactions through a feature called Subsystem Storage Protection. Some sites estimate a lack of protection to be the cause of 75% of unplanned CICS outages. In SP 5, this support has been extended to isolate transactions from one another. This new support is called CICS Subspaces Support, and confirms that a transaction has write access to storage before allowing an update to occur. This SP 5 facility is used by CICS/ESA V4.1 with the Extended Availability feature, and is hardware assisted on the following processors: ES/9000 211-based processor, ES/9000 511-based processor with SEC C35945 or higher, ES/9000 711-based processor with SEC 228250 (plus patch ZFIL2069) or SEC228270 (or higher), and the S/390 9672 Parallel Servers (PTS & PES). This feature will cause some overhead. In some benchmarks, the ITR (Internal Throughput Rate) decreased 3% to 6% when transaction isolation was turned on, and the CICS region needed an additional 9K plus 10.1K for each Subspace created. For most installations, however, this is a small price to pay to ensure CICS stability and availability. SHARED MASTER CATALOG Here's one of the most sought-after improvements: a shared master catalog! Before SP 5, you couldn’t share a master catalog because of the need to use the same name (e.g. SYS1.LOGREC) on each image. SP 5 allows you to specify a symbolic, &SYSNAME, to allow creation of unique names for each system. This allows you to define data sets for LOGREC, page and swap data sets, dump data sets, VIODSN, DUPLEX, NONVIO, SMF data sets, and SVCDUMP data sets for each system. As additional support, SMF data sets can have any valid 44-character name, and dump data sets can be dynamically named and allocated as needed. Use of a single, shared master catalog will definitely simplify systems management in a multi-image installation. The ability to have a shared master catalog also allows an installation to consider the use of a shared SYSRES. Continuing this single management support, SP 5.2 provides a new MVS System Logger, which provides an integrated logging facility for SYSLOG and LOGREC. Future subsystems are expected to exploit the system logger by using it for transaction recovery, database media failure recovery, and multisystem online log merge capabilities. MORE GOODIES There are some other neat enhancements of 5.1 that make the effort of a 5.1 migration worthwhile. Bob Rogers of IBM gave a great presentation at SHARE in August, called “MVS/ESA SP 5.1 More Goodies”, where he described some of the little-advertised new features of 5.1. Here are some items from his list of “goodies”. 1. Dynamic Dump Data Set Allocation SVC dump can operate in two modes, either by using pre-allocation data sets (which have a tendency to fill up and consume a lot of space), or by dynamically allocating them at the time the dump is produced. The advantage of dynamic allocation is that no formatting is needed, the data sets are allocated to the correct size, you don’t need to waste DASD space for unused dump data sets, and you won’t have to copy the dumps from your pre-allocated dump data sets to a unique name (it will already be allocated). The decision to use dynamic data sets can be made with an operator command, not an IPL. An operator command can show any dumps that have been dynamically created since the last IPL. 2. Enhancement of Exit Capabilities SP 5.1 provides a Dynamic Exit Facility that eases the updating and testing of exits. The parmlib member, PROGxx, which was used to support dynamic APF in SP 4.3, has a new function in SP 5. In PROGxx, you can define exit points and exit routines. You can specify multiple routines per exit point, and can replace exits dynamically. A PARMLIB conversion aid, IEFEXPR (a PDF edit macro), is provided to help in the conversion once you install 5.1. While the intention is to support all exits with this facility, currently only allocation exits and SMF exits are supported. 3. IOS Device Drain SP 5.1 has solved the problem of trying to vary a device offline. Before 5.1, a device could be varied offline, but would remain “pending” until no jobs have it allocated. Unfortunately, new jobs could allocate to it while it was in “pend” state. In 5.1, a pending device is no longer eligible for allocation, unless overridden by the operator or a Device Installation Exit. 4. IPCS Improvements There are several improvements in IPCS performance. The dump directory initialization time has been improved by allowing a CI size greater than 4096. One installation cut the time for one dump from 60 minutes to 36 seconds. Use APAR OY62871 to allow IPCS to default to the larger CI size. There are many improvements to SADMP (standalone dump) processing, including writing to multiple DASD volumes, support for EXCD non-synchronous I/O, optimized blocksizes for 3390, and automated restart. 5. Operations Support In SP 5.1, you can finally identify the system and jobname holding a device reserve with the command, “D GRS,DEV=dddd”. If the system is outside the sysplex, it’s identified by the CPU serial number. DYNAMIC TAPE ALLOCATION MVS/ESA SP 5.2, available in March 1995, will provide dynamic tape allocation very similar to JES3. This feature should simplify operations and improve throughput in many installations. DISADVANTAGES OF GOING TO MVS/ESA SP 5.1 IMMEDIATELY With all these advantages, what would keep you from moving to SP 5.1 immediately? Here are things to consider. ONE MORE CONVERSION If you’ve just converted to SP 4.2 or 4.3 from a pre-SP 4.2 release, you’ve already been through a fairly significant conversion, and may not be ready for another one. There are probably other things in your installation that need attention. The conversion to 5.1 takes a bit more time if you aren’t already positioned for it. If you’ve done all the ground work, the migration is very easy. (That’s the primary reason I'm writing about it this month.) As you'll see in the rest of this article, there are several things that could or should be done ahead of time. There are a few requirements, such as HCD, but there are several items that would result in a smoother implementation if they were completed before moving to SP 5. These include the initial implementation of SMS, and an understanding of your current workloads and response requirements. TAKES MORE RESOURCES It would make sense that these new facilities might take more resources, especially CPU. IBM has completed some benchmarks using a set of jobs running on SP 4.3 and SP 5.1. The studies are documented in GG24-3258, “MVS/ESA SP 5.1 Performance Studies.” They found that the ITRs (internal throughput rates) were slightly lower on a 5.1 system, because, like SMS, you're asking the system to do work that the systems programming staff used to do. (There are over 1.5 million lines of code to support SP 5.1 and parallel sysplex.) But I think the overhead is fairly low in comparison to what you get. IBM’s initial benchmarks show the following reductions in ITRs between SP 4.3 and SP 5.1 when running in compatibility mode: Batch workload 2% TSO/E workloads 2% to 5.5% (8-way 9021 had 2%, 1-way LPAR had 5.5%, but lower as CPU utilization increased) CICS V3.3 & DB2 workload 0% CICS V4.1 workload 3-4% IMS V3.1 workload 0% IMS V4.1 (early prototype) workload 4-5% When evaluating these results, you should be aware of several things. First, your workload will be different (not might, but will). The IBM workloads are optimally tuned. In most installations, the workloads are not optimally tuned, and may see performance improvements after moving to SP 5 simply because WLM could end up in running the workload more efficiently. For example, I’ve seen some installations that are actually restricting the performance of their systems because of a poor implementation of storage isolation. WLM will apply storage isolation dynamically only if it will improve the ability to meet your response time goals. When reviewing IBM’s benchmarks, also note that several of the IBM benchmarks were run prior to applying the 5.1 PTF UW07924, a PTF that was available on 7/6/94 to improve performance of the locking functions. Before you install SP 5.1, be sure that the 5.1 release includes the code available with this PTF. The benchmark study also indicated that the ETR (external throughput rate) didn’t change (this would indicate that response times weren’t affected). Storage usage changes in SP 5.1 of course. IBM’s benchmarks showed that virtual storage below the line got a savings of between 140K to 290K in CSA and SQA. Processor storage (central and/or expanded) increased by 4.5MB plus 1K per address space in fixed SQA. Your results may vary. WLM monitors the state of the system resources and of work running every 1/4 second and may adjust the system every two to ten seconds, while the sysprog might have been making similar changes weekly or monthly. That’s quite a change in the response to performance problems! In addition to monitoring address spaces, WLM also monitors both CICS and IMS transactions. The control of the resources is better, response times will be easier to manage, the sysprog or performance analyst will spend less time on performance problems, all because the system is doing the management of resources. Of course, this might cost you in both storage and CPU. The benchmarks mentioned above indicated that a switch from compatibility mode to goal mode caused a CPU increase of 1% to 2.5%, an ITR decrease. Some of the early customers indicated that they saw no CPU increase. Remember that these estimates are based on simply moving an existing workload to 5.1 with no alteration. Many of the facilities of 5.1 will result in an improved ITR after they’re implemented. For example, the use of data sharing in a parallel sysplex can allow you to reduce the overhead present in the current techniques, and thus will reduce the residency and CPU time for online systems accessing common data. Improvements in JES processing, the dynamic ability to manage poorly performing workloads, improvements in dump processing, and storage improvements in the newer releases of CICS and IMS are expected to improve both ITRs and ETRs. If one of your reasons to move to 5.1 is the ability to use the new lessexpensive CMOS PTS machines for your workloads, consider that the price/performance of the PTS machines will more than offset any decrease in ITR. See the item on page 5 of my SHARE trip report where Jerry Miastkowski from Allstate Insurance reported that their move to the PTS machines provided projected savings of $4.7 million in 1994, $10.3 million in 1995, and $10.6 million in 1996. Watch for a new manual that’s expected in 11/94: GG24-4352, “Workload Manager Performance Studies for MVS/ESA SP 5.1.” REQUIRES HCD This is the only real requirement of SP 5. Many sites have already moved to HCD (Hardware Configuration Definition), and have been quite happy with the results. IBM has provided a variety of conversion aids to help you, but it's not an overnight conversion. You might as well start on it now. SUMMARY For most installations, the advantages of migrating to SP 5 outweigh the disadvantages, but you’ll may need additional CPU and storage resources to support the new release. The migration can proceed in stages, however, so that you’re completely ready to make the final switch. MIGRATE TO SP 4.3 OR SP 5.1? In the last month or so, people have begun asking, "should I migrate to SP 4.3 or SP 5.1?". My answer, in all cases, is "it depends!" I've never been a fan of moving to the latest release of software immediately. I'd prefer to let the "bleeding-edge" folks test the software for me first, so my first answer would be to wait for awhile. As an example, SP 4.3 has been available since March 1993, and users are still finding new performance problems, mostly from other software vendors. SP 5.1 has only been available since the end of June this year. Besides, there's a lot of work you can do before moving to SP 5 that can just as well be done on an earlier release. (Just keep reading!). There are two situations where I'd recommend moving to SP 5.1 instead of SP 4.3, however. The first case is the business situation where POSIX client/server applications are needed in the near future. Although SP 4.3 also has support for OMVS, the 5.1 release provides more functions and facilities. The second situation occurs for sites that haven't converted to SP 4.2 yet, especially MVS/XA sites. Rather than make two conversions of your IPS, ICS, and OPT, I'd be tempted instead to move directly to SP 5.1 and use the WLM's goal mode. It will take less time overall for the conversions, and will probably result in better management of the resources. I'd suggest a couple of different things in this situation. First, wait as long as is comfortable (let other sites do the testing). Second, make sure that you've increased the amount of storage (and possibly CPU) before the conversion. You’ll be stepping past several significant releases, and the new releases will simply use more resources, especially storage. Watch out for potential problems when migrating to new levels of DFP, since you may require some toleration PTFs to avoid serious compatibility problems when accessing volumes from two releases of DFP. POSITIONING FOR MVS/ESA SP 5 If you're planning to migrate to SP 5 in the future, I'd highly recommend that you start the migration now, even if you're at MVS/XA. Many of the conversion steps to SP 5 will take weeks, if not months, and can easily be done ahead of time. The really good news is that, without exception, all of these positioning moves are good techniques to be using in any installation today. So, even if you're not planning to move to 5 any time soon, these recommendations still apply to you. The recommendations are listed in Figure 1 and are described in the following sections. Please note: This is not a duplication of, nor a replacement of, IBM’s Conversion Notebook, GC28-1435. These articles are intended to show you what can be done a year or more before you move to SP 5, not necessarily the week before you’re ready to install it. The two documents can, and should, be used in conjunction.